スクラム歴2ヶ月の私がスクラムガイドを読んでみた（感想文 & 体験談）
こんにちは。Kyoです。みなさんスクラムしてますか？
私は8月から試験的にスクラムを始めて、2ヶ月が経ちました。改めて公式ドキュメントであるスクラムガイドから気になる部分をピックアップしつつ感想と体験を述べていこうと思います。
私の立場について
- ロールとしてはソリューションアーキテクト (SA)
- 普段は一人でAWSインフラの構築・コンサルティングを行っている (同時に複数プロジェクトに関わる立場)
- スクラムマスター経験のある同僚SAと変則的なスクラムでプロジェクトを進行中
- アジャイルの考え方はとても好きだが、スクラムの経験そのものは2ヶ月とビギナー
スクラムガイドについて
- スクラムの考案者、Ken SchwaberとJeff Sutherlandによって書かれたドキュメントの日本語訳
- 「スクラム公式ガイド：ゲームのルール」というサブタイトルでルールブックという位置付け
- 表紙、目次等を含めてPDFで18ページと非常にシンプルにまとまっている
- 都度改定が行われているようで今回読んだのは「2020年11⽉版」
感想
スクラムガイドの⽬的
成⻑を続ける複雑な世界において、スクラムの利⽤は増加しており、我々はそれを⾒守っている。スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。そうした状況を⾒ると、我々も光栄である。スクラムが広まったことにより、開発者、研究者、アナリスト、科学者、その他の専⾨家もスクラムを利⽤するようになった。
スクラムはIT (ソフトウェア開発)から生まれたが、IT以外の分野でも利用可能、ということが示されています。
私のバックグラウンドは実験科学ですが、確かに今その分野でプロジェクトを始めるのであればスクラムの要素を取り入れてみたいと思います。
スクラムの定義
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織 が価値を⽣み出すための軽量級フレームワークである。
スクラムとは問題解決のためのフレームワーク、ということが示されています。
実際、始める前は「スクラムってチーム開発のイメージはあるけれど、具体的に何か全く想像つかない...」と思っていました。なお、軽量級かどうかは現在も疑問が残っています。
スクラムはシンプルである。まずはそのままの状態で試してほしい。そして、スクラムの哲学、理論、構造が、ゴールを達成し、価値を⽣み出すかどうかを判断してほしい。スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。
一人で複数プロジェクトに対応する立場としては、スクラムの概要を知ったときに「正直重たいな」と感じました。ただ、実際にやってみるとそれぞれの要素要素にしっかりと意味があることにも気づきました。
スクラムは問題解決のフレームワーク、つまり方法論なので、行っていく中で状況に合わせた変更を加えること自体は問題ないと思います。ただ、変更を加える前に素のスクラムを経験することはととても学びが多いと思っています (守破離のようなイメージ)。
なお、2020年11月版では削られていますが、2013年7月版ではスクラムの定義の中で「軽量、理解が容易、習得は困難」という表現がなされています。この部分、とても共感できて好きです。どうして削られてしまったんでしょうね？
スクラムの理論
スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
スクラムでは、予測可能性を最適化してリスクを制御するために、イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採⽤している。
スクラムを始めたてのころにまず感じたのは「レビューとふりかえり多過ぎ...？」ということでした。その根本に経験主義があることが示されています。今考えてみると、この沢山のレビューとふりかえりによって自分のスキル (純粋に技術だけではなく、ソフトスキルも含めて)の成長を感じられている気がします。さらにこれを繰り返していくことでチーム全体の成熟度が上がっていくようにも感じています。
スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである。
これを小さく繰り返していくことで、自分たちも成長しつつ大きな問題の解決につなげていきます。 三本柱である「透明性、検査、適応」は、実験科学における「仮説、実験、考察」によく似ていると感じています。
スクラムの価値基準
スクラムが成功するかどうかは、次の 5 つの価値基準を実践できるかどうかにかかっている。確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
どれも重要ですが、チームの立ち上げ期においては後半の3つ「公開、尊敬、勇気」が特に重要になると考えています。実際に立ち上げ期にチーム内でちょっとした失敗をしたことがありますが、「腹を割って話す」という方法で乗り越えることができました。この根本となるのが上記の3つであると考えています
スクラムチーム
スクラムの基本単位は、スクラムチームという⼩さなチームである。スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。
当初スクラムマスターはプロジェクトマネージャー (PM)的な機能も有すると思っていました。スクラムチームは自己管理型であり、PMが存在しないことは、ウォーターフォールと比較した場合の大きなギャップになると思います。
スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。
私にとっては3人のスクラムチームでもコミュニケーションコストがとても高いと感じました。理由は以下の組み合わせだと考えています。
- 通常SAは1人で複数プロジェクトを担当する、という現在の業務スタイル
- スクラム (前述の3本柱)故のレビューの多さ
- メンバーが増えることでコミュニケーションパスが指数関数的に増加する
これを解決するために様々な工夫を行い、ある程度コミュニケーションコストの問題を解決することはできましたが、やはり根本には1. の業務スタイルの制約が大きいと考えています。
メンバーが複数のプロジェクトを兼任すべきではない、という意見は以下のサイトにも書かれています。
スクラムイベント
スプリントは他のすべてのイベントの⼊れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運⽤しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられる。すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。
スクラムを重い、と感じたの理由の1つがこのスクラムイベントの多さでした。ただ実際にやってみると、当たり前に必要なことを定期的に行っていることが分かりました。省略されがちなふりかえりもレトロスペクティブとして、イベントに含まれていることで強制的に意識を向けさせられます。
スクラムの用語が堅苦しいと思う場合は、以下のサイトを見てみると良いと思います。
スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。スプリントの期間が⻑すぎると、スプリントゴールが役に⽴たなくなり、複雑さが増し、リスクが⾼まる可能性がある。スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができる。スプリントは短いプロジェクトと考えることもできる。
今回、スプリント期間は一週間としました。スクラムガイドに書かれている通り修正が行いやすく、チームを立ち上げたての私達にとってこれは正解であったと感じます。
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。結果としてできる計画は、スクラムチーム全体の共同作業によって作成される。
チームとしての成長、という文脈ではスプリントプランニングの練度が上がったことが印象深いです。
当初のスプリントゴールを達成できたり、できなかったり、という状態から、自分たちのキャパシティを知ることやタスクの切り方などを工夫することで当たり前にゴールを達成できる状態になりました。これはメンバーのモチベーションにかなり影響があったと思います。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
いわゆる朝会であるデイリースクラム。当初は毎日というコストもあり、あまり必要ではないと考えていたのですが、細かい問題の共有や頭出しの場として、非常に便利であることが分かりました。またチェックインとしてちょっとした雑談を行っていたのですが、これを積み重ねることでチームメンバーの価値観を知ることができ、心理的安全性の確保につながったように思います。
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
KPTで行っています。正直に言うと個人的にはKPTはProblemばかり出て、Keepが出づらいので苦手でした。今回は初期にスクラムマスターがかなりカジュアルに話せる雰囲気を作ってくれたので、ラフな意見も含めてたくさん出し、その中からどのように改善していけばいいかを話せているように感じます。初期の場作り、自分でも取り入れていきたいところです。
スクラムの作成物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最⼤化できるように設計されている。作成物を検査する⼈が、適応するときと同じ基準を持っている。
私達のチームでは、GitHubのカンバンを使ってプロダクトバックログ、スプリントバックログを管理しています。GitHubを使うことでCDKのコードと一緒にこれらを管理することができています。
プロダクトバックログはユーザストーリー (スクラムガイドには登場しない)をベースに作成しています。インフラ領域でユーザーストーリーが描けるかは不安要素もあったのですが、やってみると案外うまくいったので採用となりました。ユーザーストーリーを描くことでメンバー間での認識を揃えられたのは良かったと思います。
最後に
スクラムの役割・作成物・イベント・ルールは不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。
強いメッセージですね。
所感
本エントリでは自分の体験を元にスクラムガイドを読んでみました。
現在私達は変則的かつチーム立ち上げフェーズをすこし過ぎたあたり、ということでどうしてもチームを作っていく(アジャイルのレフトウィング)部分に目が行きがちだったかなと思います 。
スクラムガイドは全18ページ、ということで全体像を掴むぐらいのものだと考えていたのですが、一文一文が非常に濃厚で、考える度に新しい発見がありました。自身の経験値によっても得られるものも変わってきそうなので繰り返し読んでいくのが良さそうです。
最後にスクラムと言えば、と思う動画を貼っておきます。スクラムやアジャイルに興味を持っていただければ幸いです。
